Anstatt uns Gedanken darüber zu machen, wie wir unsere Anwendung so konfigurieren, dass sie auf verschiedenen Zielumgebungen läuft, können wir mit Hilfe von Containern explizit angeben, welche Art von Umgebung unsere Anwendung benötigt, und diese Umgebung dann automatisch für uns erstellen lassen. Von unserer lokalen Entwicklungsumgebung über das private Rechenzentrum unseres Unternehmens bis hin zu einem öffentlichen Cloud-Angebot wie Azure können Container uns dabei helfen, sicherzustellen, dass genau die gleiche Umgebung für das Hosting unserer Anwendung erstellt wird. Der Traum eines jeden Entwicklers! Wie aber sind wir hier gelandet? Dazu ist es hilfreich, uns zunächst anzuschauen, wie Softwareentwicklung vor dem Aufkommen von Containern aussah.
Bevor Container immer beliebter wurden, herrschten im standardmäßigen Workflow der Softwareentwicklung noch einige Probleme vor. Insbesondere die beiden nachfolgend beschriebenen waren ziemlich unbequem und erschwerten uns die Arbeit als Entwickler erheblich.
Fallstrick #1: Multiple Zielumgebungen
Der erste Fallstrick ist einer der ältesten Programmiererwitze überhaupt, vielleicht sogar älter als der über das Beenden von Vim: Das allzu häufige Problem von Anwendungen, die zwar auf unserer eigenen Maschine laufen, aber nirgendwo sonst. Als Anwendungen komplexer wurden und Entwickler Zugang zu mehr Entwicklungsumgebungen erhielten, stießen wir auf Probleme, wenn es darum ging, alles an einer Vielzahl von Orten gleichermaßen zum Laufen zu bringen. Bisweilen funktioniert eine Anwendung auf dem eigenen Rechner gut, vielleicht sogar auch bei QA und Staging – aber sobald sie in der Produktion eingesetzt wird, schlägt sie aus irgendeinem Grund fehl. Beim Debugging sieht man die Ursache in einer subtilen Abhängigkeit von der eigenen Produktionsumgebung. Vielleicht hat man eine Library-Version, z. B. Entity Framework, auf Version 6.3 aktualisiert, aber die entsprechende Abhängigkeit von .NET Core nicht auf 3.1 aktualisiert. Oder vielleicht wurde die falsche Konfigurationseinstellung angewendet, wodurch ein dev-Wert anstelle eines prod-Werts blieb. Diese Art subtiler Unterschiede in den Umgebungen bereitete Kopfschmerzen und führte nicht selten zu stundenlangem undurchsichtigem Debugging.
Ein weiteres häufiges Szenario: Neueinstellungen von Mitarbeitern. Ich weiß, dass einige Teams das inzwischen sehr gut machen, aber ich erinnere mich an die Tage, an denen neue Kollegen eingestellt wurden, und wie der Prozess der Einrichtung ihrer Entwicklungsumgebung eine ganze Woche dauern konnte. Manchmal erhalten sie den Rechner eines Vorgängers, und wenn wir Glück haben, bleiben die meisten Abhängigkeiten unserer Codebasis bestehen. Am wahrscheinlichsten ist jedoch, dass unsere neuen Kollegen einen völlig neuen oder komplett gelöschten Rechner erhalten und wir ihn von Grund auf neu einrichten müssen. Denken Sie jetzt an das letzte Mal, als Sie einem Kollegen helfen mussten, Ihre Codebasis von Grund auf neu einzurichten. Es sollte keine Überraschung sein, dass wir, nachdem wir uns mit unseren eigenen Umgebungen vertraut gemacht haben, alle gelernten Macken, zusätzlichen Schritte und die vollständige Liste der Abhängigkeiten vergessen, die erforderlich sind, um die Codebasis startklar zu machen. Diese Art von Szenarien war für Container wie geschaffen.
Fallstrick #2: Portabilität
In einer idealen Welt könnten sich alle Entwickler auf die Erstellung von Anwendungen für eine einzige Plattform konzentrieren. Die Realität sieht jedoch so aus, dass viele Anwendungen mehrere Plattformen und Geräte unterstützen müssen. Und nun, da Cloud-Anbieter immer häufiger als Hosts für unsere Anwendungen auftreten, sind Lift and Shifts in die Cloud auf die Portabilität dieser Anwendungen angewiesen. Vor der Einführung von Containern wurde das durch mühevoll erstellte Konfigurationsskripte, die Verwaltung vieler Umgebungsvariablen oder im schlimmsten Fall durch redundante und replizierte Codebasen erreicht, die auf eine bestimmte Plattform zugeschnitten waren. Zwar funktionierte das, aber es wurden viele Stunden damit verbracht, diese Kompatibilitäten für spezifische Umgebungen zu entwerfen und zu planen. Noch mehr Stunden wurden für die Fehlersuche bei Problemen aufgewendet, die durch diese unterschiedlichen Umgebungen verursacht wurden.
Was genau sind Container?
Es gibt viele Möglichkeiten, Container zu beschreiben, doch diese halte ich für die simpelste: „Ein Container ist ein unabhängiges Paket von Software und deren Abhängigkeiten.“ Im Zusammenhang mit der Softwareentwicklung erlaubt uns diese Definition, uns auf die praktische Anwendbarkeit von Containern zur Lösung der zuvor diskutierten Probleme zu konzentrieren. Schlüsseln wir diese Definition einmal auf: Was meinen wir, wenn wir von Abhängigkeiten sprechen? Das sind all die Dinge, die die Anwendung erfordert, um ihre eigene Umgebung zu bauen und darin zu laufen. Das beinhaltet natürlich unseren Quellcode, aber auch die spezifischen Laufzeiten und bestimmte Bibliotheksversionen sowie alle Konfigurationseinstellungen, die unsere Anwendung benötigt. Diese Abhängigkeiten werden dann zu einem unabhängigen Paket gebündelt. Das Paket ist portabel, vorhersehbar und zuverlässig, weil es alles enthält. Zu diesem Zeitpunkt kümmert es uns nicht und es spielt auch keine Rolle, wo dieses Paket eingesetzt wird; das Paket ist selbsterhaltend. Diese Option hat sich bei der Lösung der kniffligen Probleme, die wir besprochen haben, als effektiv erwiesen. Vorbei sind die Zeiten des umgebungsbezogenen Troubleshootings und Debuggings. Neue Kollegen haben nicht mehr eine lange Anlaufzeit, um ihre Entwicklungsumgebung korrekt einzurichten. Durch die Containerisierung der Anwendungen muss sich das Entwicklungsteam mit vielen der Problemszenarien nicht mehr herumplagen.
Container-Services in Azure
Falls Sie sich jetzt fragen, wie das Ganze zu bewerkstelligen ist, zeige ich Ihnen gerne, wie das geht – und zwar mit den Azure Container Services. Im Speziellen bietet Azure die folgenden vier an:
- Azure Container Registry
- Azure Container Instance
- Azure Web App für Container
- Azure Kubernetes Service
Wir werden nachfolgend besprechen, was jeder dieser Services ist bzw. nicht ist, und entsprechende Demos anschauen.
Azure Container Registry
Genauso, wie wir unseren Quellcode versionieren und verteilen können, können wir das mit Container-Images tun. Das sind die statischen Dateien, die als Snapshots für unsere eigentlichen Container dienen. Sie enthalten die Anweisungen und Abhängigkeiten, die man zum Bau eines Containers benötigt. Man kann sich Container-Images als Rezepte für einen Kuchen und Container als tatsächliche Instanzen dieses Kuchens vorstellen. Aber zurück zur Repo-Analogie: Azure Container Registries sind die Repos für Container-Images. Sie sind eine Möglichkeit, Container-Images mit anderen zu teilen und zu verteilen, insbesondere innerhalb eines Teams. Wer mit Docker Hub, der öffentlich zugänglichen Open-Source-Quelle für beliebte Basis- und offizielle Images, vertraut ist, kann sich Azure Container Registry in Analogie zu den privaten Repositories von Docker Hub vorstellen. Und genau das ist es, was eine Azure Container Registry ist: ein privater, verwalteter Registry-Dienst. Eine praktische Tatsache der Azure Container Registry ist, dass sie auf der Open-Source-Implementierung von Docker Registry 2.0 basiert. Das bedeutet, dass die Container Registry Docker-kompatible Images sowie grundsätzlich alle Images und Artefakte unterstützt, die der OCI-Spezifikation (Open Container Initiative) entsprechen.
Wie die meisten Azure-Dienste ist auch die Azure Container Registry (zum Zeitpunkt des Schreibens dieses Artikels) in drei Editionen verfügbar:
- Basis
- Standard
- Premium
Basis: Die Basisedition ist die kostengünstigste und eignet sich am besten für persönliche Projekte und kleine Demos wie die, die später in diesem Artikel zu finden ist. Obwohl diese Option alle Kernfunktionen der Standard- und Premiumeditionen bietet, eignet sie sich mit ihren Speicher- und Durchsatzangeboten besser für Prototypen und den Einstieg in die Arbeit mit Containern.
Standard: Diese am häufigsten gewählte Edition dürfte für die meisten Teams passend sein. Sie bietet mehr Speicherplatz und einen höheren Durchsatz als die Basisedition und sollte für die meisten Produktionsszenarien ausreichen.
Premium: Es ist immer wieder interessant zu sehen, was die kostenintensivste Option von den anderen abhebt. Diese Edition ist am besten für Teams geeignet, die sich vollends Containern widmen. Sie ist auch diejenige, die man in Erwägung ziehen sollte, wenn man ein paar zusätzliche Features benötigt, um containerbasierte Lösungen zu unterstützen.
Zunächst einmal bietet die Premiumedition den höchsten Durchsatz, wodurch sie sich perfekt für Docker Pulls über mehrere simultane Nodes eignet. Wer schon ein paar Images gesehen hat, weiß, dass sie manchmal recht groß sein können, sodass zusätzliche Leistung für Szenarien mit hohem Datenaufkommen äußerst wertvoll ist. Darüber hinaus ist die Premiumedition die einzige Edition, die Georeplikation, Content Trust (für die Signierung von Image-Tags mit dem Content-Trust-Modell von Docker), Private Link (mit 10 privaten Endpoints) und vieles mehr unterstützt. Die vollständige Aufschlüsselung der verschiedenen Editionen der Azure Container Registry bietet weitere Informationen. Und schließlich können, so wie auch Repos das Ziel von Continuous-Integration-Workflows sind, Container-Registries das Ziel für Containerentwicklungsworkflows sein. Die meisten Softwareentwicklungsworkflows sind an diesem Punkt ziemlich standardisiert (oder nähern sich diesem Standard an): Entwickler genehmigen einige Änderungen in einem Pull Request, führen diese Änderungen in ihrem Hauptentwicklungszweig zusammen, triggern einen Build, führen einige Tests durch und automatisieren möglicherweise das Deployment, nachdem ein erfolgreicher Build ein Build-Artefakt ergeben hat. Ähnliche Aufgaben im Containerentwicklungsworkflow können mit Azure Container Registry Tasks automatisiert werden, auch bekannt als ACR Tasks. Zu den häufig automatisierten Aufgaben gehören das Rebuildung von Images, wenn sich die Base Images geändert haben, und das Patchen des Betriebssystems und der Frameworks auf Docker-Container.
Tutorial: Azure Container Registry via Azure CLI erstellen
Anstatt nur darüber zu reden, wie großartig Azure Container Registries sind, können wir nun eines erstellen – und das geht recht schnell. Achtung: Um dieser und den weiteren Demos zu folgen, werden ein Azure-Account und ein Azure-Abonnement sowie das auf den Computer heruntergeladene Azure CLI benötigt. Zudem werden etwas Vertrautheit mit Docker und einige Docker Images auf dem Computer vorausgesetzt. Die Schritte sind wie folgt:
1. Auf einem Terminal seiner Wahl in Azure einloggen; das sollte zu einer Weiterleitung in den Browser führen, wo das Einloggen und Authentifizieren mit Azure erforderlich sind:
az login
2. Eine Resource Group erstellen:
az group create --location <REPLACE-WITH-LOCATION> --name <REPLACE-WITH-RESOURCE-GROUP-NAME> --subscription <REPLACE-WITH-YOUR-SUBSCRIPTION>
An dieser Stelle müssen die genannten Parameter mit den eigenen ersetzt werden. Beispielsweise sieht mein Befehl wie folgt aus:
az group create --location westus2 --name rg_westus2_registry --subscription adrienne-demos
Diese Resource Group wird unserer Container-Registry gewidmet. Das ist eine gute Praxis, die man im Auge behalten sollte, zumal es verbreitet ist, mehrere Ressourcen in einer Resource Group zu haben. Der Grund dafür, dass wir unsere Container-Registry in einer eigenen Resource Group halten wollen, ist, dass wir das versehentliche Löschen von gemeinsam genutzten Container-Images verhindern wollen. Wird die Container-Registry zusammen mit etwas weniger Permanentem gruppiert, z. B. einer Azure-Container-Instanz, ist es wahrscheinlicher, dass die Image-Sammlung beim Löschen der Containerinstanz unbeabsichtigt gelöscht wird. Das vergisst man leicht, also behalten wir die Container-Registry einfach in einer separaten Resource Group, um sicherzustellen, dass deren Löschung explizit erfolgt.
3. Zum Schluss erstellen wir die Container-Registry:
az acr create --resource-group <REPLACE-WITH-NEWLY-CREATED-RESOURCE-GROUP> --name <REPLACE-WITH-REGISTRY-NAME> --sku basic
Mein Befehl sieht beispielsweise so aus:
az acr create --resource-group rg_westus2_registry --name adrienneDemoRegistry --sku basic
Wenn das erfolgreich war, erhalten wir ein großes Objekt als Ausgabe. Innerhalb dieses Objekts suchen wir den Key loginServer und merken uns dessen Wert. Das ist der vollqualifizierte Registry-Name, der in den späteren Tutorials benötigt wird. Mein vollqualifizierter Registry-Name ist beispielsweise adrienneDemoRegistry.azurecr.io. Glückwunsch, Sie haben soeben Ihre erste eigene Azure Container Registry erstellt! Jetzt sind wir bereit, Images zu erhalten.
Tutorial: Push eines Image zur Azure Container Registry
Bevor wir mit unserer Registry arbeiten können, müssen wir uns zunächst einloggen:
az acr login --name <REPLACE-WITH-YOUR-REGISTRY-NAME>
Auf meinem Computer habe ich bereits einige Docker Images, die ich verwenden möchte. Sollten keine auf dem eigenen Computer vorhanden sein, kann das aci-helloworld-Image heruntergeladen und für den Rest des Tutorials verwendet werden. Wenn man einige Images bezogen hat, können verfügbare Images durch Eingabe des folgenden Docker-Befehls aufgelistet werden:
docker images
Suchen wir nun nach dem Image, das wir verwenden möchten, und taggen es mit dem vollqualifizierten Namen unseres Azure-Container-Registry-Servers:
docker tag <REPLACE-WITH-NAME-OF-IMAGE> <YOUR-REGISTRY-NAME>.azurecr.io/<REPLACE-WITH-NAME-OF-IMAGE>:1
Zum Beispiel sieht mein Befehl so aus:
docker tag aci-hello-demo adrienneDemoRegistry.azurecr.io/aci-hello-demo:1
Es fällt auf, dass hinter dem Image-Namen :1 steht. Dabei handelt es sich um einen Stable Tag. Wir taggen das Image so, weil es die erste Major-Version dieses Image – die zufälligerweise ein Base Image ist – sein wird, das wir zur Registry pushen. Es ist eine gute Idee, Stable Tags für Images zu verwenden, die Updates und Patches erhalten sollen. Stable Tags sollten in Deployments allerdings vermieden werden.
Schließlich pushen wir das getaggte Image zu unserer Registry:
docker push <YOUR-REGISTRY-NAME>.azurecr.io/<YOUR-IMAGE-NAME>:1
Mein Befehl sieht beispielsweise so aus:
docker push adrienneDemoRegistry.azurecr.io/aci-hello-demo:1
Das Image sollte nun in unserer Registry sein. Wir können das mit dem folgenden az-list-Befehl prüfen:
az acr repository list --name <YOUR-REGISTRY-NAME> --output table
Wir haben nun verteilbare Images, aber wo verteilen wir sie? Und wo sind die Container? Hier kommen die anderen beiden Azure Container Services ins Spiel.
Azure Container Instance
Nachdem wir einen Ort zum Speichern und Verteilen unserer Images erstellt haben, gibt es verschiedene Möglichkeiten, sie zu Containern zu deployen. Die erste Option ist Azure Container Instance. Um etwas möglichst schnell zum Laufen bringen oder zu testen, oder wenn man zum ersten Mal mit Containern experimentiert, ist Azure Container Instance die erste Wahl in Azure. Da es vollkommen von Azure gemanagt ist, stellt es auch den einfachsten Weg dar, einen Container in Azure zu betreiben. Wenn einem also nichts an der unterliegenden Infrastruktur seiner Container liegt oder man sich nicht darum kümmern will, sind Azure Container Instances das Mittel der Wahl. Wie bei vielen anderen Rechenleistungen muss man auch hier nur für die Ressourcen zahlen, die man beim Ausführen einer Azure Container Instance verwendet. Wenn man das im Hinterkopf behält, ist es am besten, diese Container für kleinere Projekte und Single Applications zu verwenden. Anwendungen können in ihrem Leistungsverbrauch allerdings stark variieren. Um sich daran anzupassen, bietet Azure Container Instance die Möglichkeit, die exakten CPU-Kerne und den Speicher einzugeben, den man benötigt. Das ist entscheidend, wenn es um den Feinschliff der Ressourcenoptimierung und damit schließlich um die Kosteneinsparung geht.
Kommen wir nun zum praktischen Teil dieses Tutorials und beginnen wir mit dem Deployment eines Containers.
Tutorial: Eine Azure Container Instance erstellen und ein Image zu einem Container deployen
Zuerst werden wir eine weitere Resource Group erstellen, um die Containerinstanz zu beinhalten:
az group create --name <REPLACE-WITH-RESOURCE-GROUP-NAME> --location <REPLACE-WITH-LOCATION>
Mein Befehl sieht beispielsweise so aus:
az group create --name rg_westus2_aci --location westus2
Jetzt müssen wir nur noch einen Container erstellen und das gewünschte Image deployen. Wir können das in einem einzigen Befehl mit ein paar Parametern erledigen, wie in Listing 1 gezeigt wird.
az group create --location <REPLACE-WITH-LOCATION> --name <REPLACE-WITH-RESOURCE-GROUP-NAME> --subscription <REPLACE-WITH-YOUR-SUBSCRIPTION>
An dieser Stelle stellt sich vielleicht einigen die Frage, woher man Registry-Nutzernamen und -Passwort bezieht. Da wir unser Image aus unserer eigenen privaten Azure Container Registry beziehen, werden wir einige Credentials im Befehl in Listing 1 angeben müssen, um Zugriff auf die Registry zu erhalten. Die Best Practice hierfür ist, ein neues Azure Active Directory Service Principal zu erstellen und mit pull-Rechten zu konfigurieren (Listing 2). Man kann auch einen bestehenden Service Principal mit zugewiesener acrpull-Rolle nutzen (Listing 3).
# Source: https://docs.microsoft.com/en-us/azure/container-registry/container-registry-auth-aci#create-a-service-principal #!/bin/bash # Modify for your environment. # ACR_NAME: The name of your Azure Container Registry # SERVICE_PRINCIPAL_NAME: Must be unique within your AD tenant ACR_NAME=<container-registry-name> SERVICE_PRINCIPAL_NAME=acr-service-principal # Obtain the full registry ID for subsequent command args ACR_REGISTRY_ID=$(az acr show --name $ACR_NAME --query id --output tsv) # Create the service principal with rights scoped to the registry. # Default permissions are for docker pull access. Modify the '--role' # argument value as desired: # acrpull: pull only # acrpush: push and pull # owner: push, pull, and assign roles SP_PASSWD=$(az ad sp create-for-rbac --name http://$SERVICE_PRINCIPAL_NAME --scopes $ACR_REGISTRY_ID --role acrpull --query password --output tsv) SP_APP_ID=$(az ad sp show --id http://$SERVICE_PRINCIPAL_NAME --query appId --output tsv) # Output the service principal's credentials; use these in your services and # applications to authenticate to the container registry. echo "Service principal ID: $SP_APP_ID" echo "Service principal password: $SP_PASSWD"
# Source: https://docs.microsoft.com/en-us/azure/container-registry/container-registry-auth-aci#use-an-existing-service-principal #!/bin/bash # Modify for your environment. The ACR_NAME is the name of your Azure Container # Registry, and the SERVICE_PRINCIPAL_ID is the service principal's 'appId' or # one of its 'servicePrincipalNames' values. ACR_NAME=mycontainerregistry SERVICE_PRINCIPAL_ID=<service-principal-ID> # Populate value required for subsequent command args ACR_REGISTRY_ID=$(az acr show --name $ACR_NAME --query id --output tsv) # Assign the desired role to the service principal. Modify the '--role' argument # value as desired: # acrpull: pull only # acrpush: push and pull # owner: push, pull, and assign roles az role assignment create --assignee $SERVICE_PRINCIPAL_ID --scope $ACR_REGISTRY_ID --role acrpull
Wenn wir den gewünschten Service Principal konfiguriert haben, notieren wir uns die Service Principal ID und das Service-Principal-Passwort, denn das werden die Werte sein, die wir in den Parametern —registry-username und —registry-password eintragen.
Der Befehl wird mit den eigenen Parametern vervollständigt und dann ausgeführt. Zum Beispiel sieht mein Befehl aus, wie in Listing 4 gezeigt.
az container create -g rg_westus2_aci --name aci-hello-adrienne --image adrienneDemoRegistry.azurecr.io/aci-hello-demo:1 --dns-name-label hello-adrienne --ports 80 --registry-username AdrienneServicePrincipalId --registry-password AdrienneServicePrincipalPassword
Durch das Ausführen dieses Befehls erstellt Azure den Container, findet das spezifizierte Image und deployt es via einer Azure Container Instance zum Container. Warten wir einen Moment, und wenn wir ein weiteres großes Objekt als Ausgabe erhalten, wissen wir, dass der Befehl erfolgreich verlaufen ist. In diesem Objekt finden wir den fqdn-Schlüssel und kopieren dessen Wert. Wenn er in den Browser eingefügt wird, sollten wir die Anwendung betrachten können, die innerhalb eines Containers und somit innerhalb einer Azure Container Instance läuft.
Nach Beenden dieser Demo dürfen wir nicht vergessen, die Containerinstanz zu löschen. Aus diesem Grund war es praktisch, eine separate Resource Group zu erstellen. Wir können jetzt einfach die Containerinstanz löschen, aber die Container-Registry und somit auch Container-Images behalten. Das wird umso wichtiger, je mehr Images in der Container-Registry gespeichert oder mit anderen Teammitgliedern geteilt werden.
So löschen wir die Containerinstanz:
az group delete --name <YOUR-CONTAINER-RESOURCE-GROUP>
Azure Web App für Container
Für langlaufende Anwendungen oder zusätzliches Tooling ist Azure Web App für Container das Mittel der Wahl. Hier können wir die Azure-App-Service-Features nutzen, die möglicherweise schon bekannt sind, sowie auch die besser vorhersehbaren Preismodelle, die in App Services enthalten sind. Dinge wie Deployment Slots für Anwendungsupdates, integrierte Load Balancer, Unterstützung für Traffic-Manager zur Ermöglichung von Multi-Region Failover und vieles weitere werden von Azure Web Apps für Container unterstützt, nicht aber von Azure Container Instances.
Ein weiteres Szenario, für das Azure Web App für Container besser geeignet ist, sind Always-on-Umgebungen, z. B. dedizierte Dev- oder Testumgebungen. Das vorhersehbare Preismodell und flexible Skalierungsoptionen sind dafür geradezu prädestiniert.
Azure Kubernetes Service
Und schließlich gibt es noch Azure Kubernetes Service oder kurz AKS. Diese Option ist am besten für Teams geeignet, die sich ganz dem containerbasierten Ansatz verschrieben haben und sich bereits mit Kubernetes auskennen. Zum Betreiben multipler Container und wenn man einen Hands-off-Ansatz verfolgt, um Cluster zu managen, ist AKS eine großartige Option. Es nimmt dem Team viel an Komplexität und Overhead und übergibt diese stattdessen an Azure. Mühevolle Aufgaben wie Maintenance und Health Monitoring werden von Azure übernommen. AKS selbst ist kostenlos. Man hat einzig die finanzielle Verantwortung für die tatsächlichen Ressourcen, die der Cluster verbraucht. Unter der Haube sind die AKS Nodes in unserem Cluster lediglich Azure VMs, sodass Instanzen, Speicher und Netzwerkressourcen, die wir verwenden, in Rechnung gestellt werden. AKS ist eine solide Wahl, wenn man die flexibelste und zukunftsträchtigste gemanagte Containerumgebung nutzen möchte. Es ist als Kubernetes-konform CNCF-zertifiziert und folgt vielen allgemeinen regulatorischen Compliance-Anforderungen, darunter SOC, ISO, PCI DSS und HIPAA.
Die Qual der Wahl
Wenn Sie sich noch unsicher sind, welcher Azure Container Service für Sie der richtige ist, können Sie sich in Abbildung 1 einen Überblick über die Unterschiede verschaffen.
Das war’s schon! Ich hoffe, dass ich Ihnen hiermit die Azure Container Services etwas näherbringen konnte.
